Archiving System States by Persistent Objects

This paper describes one speciic aspect of the software component construction in the life cycles of computer based systems. The construction is located following the requirements analysis, conception and design. Systems are designed as within the ECBS process so called services which consist of a set of objects working together, keeping the states of the system. To ensure an eecient and rapid construction of systems an easy to use mechanism to store and retrieve objects together with their relations is necessary. This demands an embedded method of keeping objects in a database | the persistence. The described mechanism is implemented using C++ and veriied in some projects. In this paper a man machine service is used as an example to show the application of this approach. 1 Overview Booch 2] writes, that object persistence is the property of on object through which its existence transcends time and/or space. This rst allows an object to survive the lifetime of an application, the second enables an object to move from one address space to an other. This paper describes an approach for persistence in time together with a subset of persistence in space: Objects can be located somewhere on a distributed system, but there is no mechanism realized to move them around. Object persistence is necessary for several reasons: Reusability After the restart of a system it could be necessary to reuse precalculated or entered states. Memory restrictions Many systems consists of very large state values. Due to memory restrictions it is sometimes not possible or signiicant to hold the entire state in memory. Safety A fatal system error often causes a total lost of information. This is in most applications not tolerable. Relations In addition to Booch we demand the possibility to keep the relations between objects persistent. Data sharing allows diierent applications to use the same information. Together with a suitable access management this results in an object oriented database. To assure this functionality in traditional systems, often an application dependent store-and-load mechanism is used to write and restore the object's contents. This can be done by placing objects into a special container object, which itself is responsible for the object management. This has one major disadvantage: Persistent objects cannot be treated like other non-persistent objects. A much better approach is to request an object to save its own state or to restore it, because of the following main advantages: …